The processing of electronic payment transactions typically requires coordination between various payment processing entities such as merchants, acquirers, acquirer processors, issuers, issuer processors, and payment processing networks. For example, the authorization of an electronic transaction may involve the exchange of authorization messages amongst the payment processing entities. When a consumer makes a purchase at a merchant using a credit or debit card, the card may be swiped or scanned at an access device such as a point of sale terminal at the merchant location. The terminal may generate an authorization request message that is routed through an acquirer and/or acquirer processor to a payment processing network. If the authorization request message is rejected by the payment processing network, the merchant can be notified and the transaction canceled. If the authorization request message is accepted, the payment processing network can then route the message to an issuer of the consumer's account and/or the issuer's processor. The issuer or processor can then perform a number of authentication, authorization, and fraud detection steps to determine whether to authorize the transaction. Upon making an authorization decision, an authorization response message can be transmitted by the issuer or processor back to the merchant—via the payment processing network and the various payment processing entities—indicating whether the electronic payment transaction is approved or declined.
The payment processing entities that participate in electronic transaction processing may each rely on terminals, server computers, and/or other hardware and software to facilitate the exchange of authorization messages. From time to time, however, hardware and software failures can occur that adversely affect the exchange of authorization messages amongst the payment processing entities. For example, if one or more of the payment processing entities is unable to communicate with the payment processing network or the other processing entities due to a failure, the issuer may not receive the authorization request message, the merchant may not receive the authorization response message, and the electronic transaction may not be completed. Hardware and software failures can also result in authorization messages being generated that contain invalid or corrupted data. Such messages may result in the payment processing network rejecting the message and canceling the transaction, or the issuer declining an otherwise valid and legitimate transaction. The above issues may affect all transactions processed by a particular processing entity. In some circumstances, however, hardware and software failures may result in intermittent issues affecting only certain transactions. Such failures may be more difficult to detect.
Existing computational solutions to the problem of detecting hardware and software failures in electronic payment processing systems are inefficient, memory-intensive, and inaccurate. For example, payment processing entities have historically relied on internal data monitoring mechanisms to detect hardware and software failures affecting their ability to receive, process, and transmit messages relating to electronic payment transactions. As explained above, however, payment processing issues experienced by one processing entity may be related to a hardware or software failure at another processing entity. Thus, some existing solutions require the analysis of transaction data from multiple sources in potentially disparate data formats. The aggregation and normalization of disparate data from multiple payment processing entities can be a time-consuming and memory-intensive process. Moreover, since certain failures result in only intermittent issues and are thus difficult to detect, the data collected and analyzed by existing solutions may not accurately portray the nature and source of the hardware or software failure.
One existing solution involves the monitoring of transactions at a payment processing network to detect an issuer's rejected transactions and other processing issues that may indicate a hardware or software failure at the issuer. If a potential failure is identified, a system operator at the payment processing network is provided with an alert message on a computer screen. This message may prompt the operator to contact the issuer by telephone to bring the potential failure to the issuer's attention. In this solution, however, transactions for other payment processing entities such as merchants, acquirers, and processors are not monitored. Moreover, the alerts provided are continuously generated until the incidence of processing issues for the issuer falls below a baseline level. Such continuous alert generation is computationally inefficient and memory-intensive.
Moreover, payment processing entities typically earn revenue on a per transaction basis, and rejected or declined transactions often result in lost sales to merchants, lost switch fees to payment processing networks, and lost interchange revenue to issuers, acquirers, and processors. In other words, rejected or declined transactions may result in lost revenue for all payment processing entities involved. Thus, it is essential that payment processing entities be made aware of hardware and software problems as soon as possible so that repairs can be made in a timely manner.
Embodiments of the invention address the above problems, and other problems, individually and collectively.